Summary

• Restores proper TypeScript type inference for onChange callback parameter
• Reverts discriminated union changes that broke type narrowing
• Adds type inference tests to prevent regression

Problem

After upgrading to 9.1.0, TypeScript could not infer the type of the onChange parameter:

<DatePicker
  onChange={(x) => {
    // x was inferred as 'any' instead of 'Date | null'
  }}
/>

This caused the error: "Parameter 'x' implicitly has an 'any' type. (7006)"

Root Cause

Commit 3a82fd1 changed selectsRange: true and selectsMultiple: true to optional (selectsRange?: true and selectsMultiple?: true) in the discriminated union type. This prevented TypeScript from narrowing the union when neither prop is specified, causing all three onChange signatures to be valid simultaneously.

Solution

Restore the required discriminators:

• selectsRange: true (not optional)
• selectsMultiple: true (not optional)

This allows TypeScript to properly narrow the type when neither prop is passed.

Impact on #6131

The original fix (#6131) was for wrapper components spreading props. Those users can work around this with a type assertion:

// Wrapper component workaround
<DatePicker {...(props as DatePickerProps)} />

This is acceptable because:

1. The 99% use case (basic DatePicker) now has proper type inference
2. Wrapper component authors are a smaller, more sophisticated audience who can use type assertions
3. Users of selectsRange and selectsMultiple already pass these props explicitly (required for runtime behavior)

Test plan

• Added type_inference_test.test.tsx to verify TypeScript can infer types without explicit annotations
• Reverted test workarounds that added explicit type annotations
• CI should pass type-check and tests

Fixes #6202

🤖 Generated with Claude Code